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Chapter  One 
REQUIREMENTS  SPECIFICATIONS  FOR  SYSTEM  DEVELOPMENT 

Requirements  specifications  are  the  basis  for  develop- 
ing a  system.   The  requirements  specification  should  define 
the  problem  and  outline  the  characteristics  (including  con- 
straints) of  a  correct  solution,  encompassing  "everything 
necessary  to  lay  the  groundwork  for  subsequent  stages  in 
system  development"  [Ro77c].   To  achieve  this  goal,  these 
specifications  must  answer  all  questions  that  arise  about 
what  the  system  should  do  when  completed.   If  a  problem  is 
well-defined  in  the  requirements  specification,  the  task  of 
developing  a  solution  becomes  much  easier. 

Many  specification  methodologies  exist  for  use  in 
requirements  specification.   Some  of  the  current  methodol- 
ogies are  E-R-L,  PSL/PSA,  SADT,  and  TAGS.   E-R-L  (Entity- 
Relationship-Level)  [Gu84]  is  a  model  based  on  an  entity- 
relationship  viewpoint.   The  E-R-L  model  uses  frames  for 
entities  and  relationships  between  entities,  and  includes 
the  ability  to  have  abstraction  levels  and  meta-informa- 
tion.   The  implementation  of  various  automated  support 
tools  has  been  planned,  with  a  frame-editor  currently  in 
operation. 

PSL/PSA  (Problem  Statement  Language /Problem  Statement 
Analyzer)  ITe77]  is  a  computer-aided  structured  documen- 
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tatlon  and  analysis  system.  It  uses  a  fixed  set  of  objects 
and  strongly  typed  relationships  between  objects.  Through- 
out the  specification  process,  textual  information  is 
entered  Into  a  database,  where  it  can  be  accessed  for  anal- 
ysis to  produce  various  reports  dealing  with  such  things  as 
object  usage,  system  hierarchy,  and  modification  diagnos- 
tics. 

SADT  (Structured  Analysis  and  Design  Technique)  [Ro85] 
Is  a  graphic,  hierarchical  dataflow  model.   SADT  combines 
graphic  language  primitives  with  natural  language  to  pro- 
duce a  hierarchical  model  with  abstraction  levels.   At 
present,  attempts  are  In  progress  to  develop  graphic  auto- 
mated support  tools. 

Finally,  TAGS  (Technology  for  the  Automated  Generation 
of  Systems)  [S185]  is  a  system  that  combines  an 
Input/Output  Requirements  Language,  with  a  system/software 
computer-based  tool  system.   TAGS  combines  dataflow 
information  along  with  control  and  timing  Information 
within  a  hierarchy  of  diagrams.   This  Information,  when 
accessed  through  the  system  database,  enables  error 
checking  and  system  simulation. 

Today,  dataflow  models  are  among  the  most  popular  in 
use  for  requirements  specification.   Dataflow  models  are 
popular  because  they  are  "very  well  suited  for  modeling  the 
structure  and  behavior  of  most  human  organizations"  [Rm85]. 
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structured  Analysis  (which  Is  part  of  SADT)  is  a  well-known 
example  of  a  dataflow  model. 

STRUCTURED  ANALYSIS  DIAGRAMS 

Structured  Analysis  diagrams  are  a  requirements  speci- 
fication tool  for  developing  large  scale  systems.   Struc- 
tured Analysis  diagrams  combine  the  conciseness  of  a 
graphic  system  with  the  expressiveness  of  a  natural  or 
formal  language  embedded  within  the  diagrams  [Ro85].   The 
choice  of  embedded  language  is  specific  to  the  type  of 
system  being  developed.   By  having  the  ability  to  incor- 
porate any  embedded  language.  Structured  Analysis  diagrams 
are  a  specification  tool  that  is  "universal  and  unrestric- 
ted," making  Structured  Analysis  diagrams  a  domain- 
independent  system  model  [Ro77b].   Structured  Analysis 
diagrams  are  a  means  of  precisely  specifying  a  system, 
analogous  to  industrial  blueprints  [Rm85].   The  concise  and 
complete  combination  of  word  and  picture  documentation 
enables  the  "rigorous  expression  of  high-level  ideas  that 
previously  had  seemed  too  nebulous  to  treat  technically" 
[Ro85].   The  requirements  specification  begins  at  a  high 
level  of  abstraction.   Through  decomposition,  the  system  is 
broken  down  into  a  hierarchically  related  set  of  diagrams. 

System  complexity  is  managed  in  Structured  Analysis  by 
restricting  a  diagram  to  six  or  fewer  parts.   The  notation 
used  in  Structured  Analysis  decomposition  is  very  straight 
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forward.   Each  of  the  six  or  fewer  parts  is  represented  as 
a  single  box.   The  left  side  of  the  box  shows  all  inputs  to 
the  box,  the  right  side  shows  all  outputs  from  the  box,  the 
top  shows  controls,  and  the  bottom  shows  mechanisms.   The 
outputs  are  transformed  from  the  inputs  under  the  direction 
of  the  control,  and  the  mechanism  is  the  means  of  the 
transformation.   The  inputs,  outputs,  controls,  and  mech- 
anisms are  represented  by  arrows,  which  connect  the  various 
boxes,  thus  indicating  relationships  between  the  boxes 
tRo77b].   When  combined,  the  boxes  and  arrows  form  a  detail 
diagram.   The  top-level  detail  diagram  must  completely 
encompass  the  breadth  of  the  system. 
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Figure  1-1  shows  a  possible  decomposition  for  a  simple 
student  database  for  use  in  managing  student  transcripts. 
The  system  has  three  major  acitivites:   CREATE  STUDENT, 
PRODUCE  TRANSCRIPT,  and  MODIFY  TRANSCRIPT.   One  input, 
STUDENT  INFORMATION,  is  required  for  the  system,  with  three 
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system  commands,  CREATE,  PRODUCE,  and  MODIFY,  controlling 
the  transformation  of  the  input  into  the  various  outputs, 
CREATE  MESSAGE,  TRANSCRIPT,  and  MODIFY  MESSAGE. 

HIERARCHY  IN  STRUCTURED  ANALYSIS  DIAGRAMS 

If  any  of  the  parts  contained  within  the  detail  dia- 
gram are  not  fully  specified,  the  decomposition  process 
continues.   The  decomposition  process  forms  a  hierarchy  of 
diagrams.   Each  box  that  is  further  decomposed  Is  known  as 
a  parent  box,  and  the  diagram  in  which  it  is  originally 
located  is  known  as  the  parent  diagram.   The  parts  of  a 
parent  box  are  placed  in  a  separate  detail  diagram,  once 
again  with  six  or  fewer  boxes.   This  new  detail  diagram  Is 
an  in-depth  description  of  the  parent  box  from  which  It  Is 
derived,  and  encompasses  the  breadth  of  the  parent  box. 
For  any  part  that  still  requires  further  specification,  the 
hierarchical  decomposition  continues  [Ro77b].   When  the 
decomposition  is  complete,  the  set  of  diagrams  will  encom- 
pass the  depth  of  the  system,  with  each  complete  abstrac- 
tion level  In  the  hierarchy  encompassing  the  breadth  of  the 
system. 

Figures  1-2,  1-3,  and  1-4  show  a  possible  hierarchical 
decomposition  of  the  parent  diagram  In  figure  1-1.   The 
CREATE  STUDENT  activity  Is  detailed  in  figure  1-2,  the 
PRODUCE  TRANSCRIPT  activity  is  detailed  In  figure  1-3,  and 
the  MODIFY  TRANSCRIPT  activity  Is  detailed  In  figure  1-4. 
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The  abstraction  process  that  gives  Structured  Anal- 
ysis much  of  its  power  can  also  cause  a  problem:   inconsis- 
tency in  naming  information  at  different  abstraction 
levels.   Except  for  the  most  trivial  of  systems,  a  Struc- 
tured Analysis  specification  will  contain  numerous  dia- 
grams.  This  introduces  the  possibility  of  naming  incon- 
sistencies across  diagram  boundaries. 
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CONSISTENCY  IN  SPECIFICATIONS 

The  requirements  specification's  main  task  is  "to  be 
able  to  answer  questions"  [Gu84],  but  an  inconsistent 
specification  is  unable  to  perform  this  task  because  the 
specification  contains  contradictions.   When  examined  as  a 
whole,  the  various  parts  of  a  consistent  requirements 
specification  will  not  contradict  one  another  [Rm85]. 
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When  working  with  a  hierarchical  methodology  such  as 
Structured  Analysis,  one  area  where  inconsistencies  are 
prevalent  is  where  information  crosses  between  levels  of 
the  system.   In  Structured  Analysis  diagrams,  inputs, 
outputs,  and  controls  are  in  this  category.   Specifically, 
the  inputs  (and  also  outputs  and  controls)  of  a  detail 
diagram  must  match  those  from  the  parent  box  at  the  next 
higher  level  In  the  model. 

As  an  example  of  this  problem,  examine  figures  1-1  and 
1-2.   In  figure  1-1,  activity  CREATE  STUDENT  requires  one 
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input:   STUDENT  INFORMATION.   In  figure  1-2,  this  input  has 
been  changed  to  read  STUDENT  ID.   When  examined  indivi- 
dually, the  diagrams  seem  to  be  correct;  but  when  examined 
together,  it  can  be  shown  that  an  inconsistency  has  already 
been  introduced  at  the  first  level  in  the  decomposition 
hierarchy.   This  problem  increases  as  the  size  of  the 
specified  system  increases  and  can  become  worse  when 
different  people  specify  different  parts  of  the  system. 

The  requirements  specification  should  be  analyzable 
for  consistency.   In  fact,  consistency  checking  "presup- 
pose(s)  the  analyzabi 1 i ty  of  the  requirements  by  (various) 
means,"  either  manually,  or  by  automated  tools  [Rm85].   To 
make  analysis  possible,  the  requirements  specification  must 
be  formalized.   Furthermore,  with  more  formality,  it  be- 
comes more  likely  that  the  analysis  can  and  will  be  per- 
formed by  mechanical  means  [Rm85].   Mechanical  analysis  Is 
advantageous  since  automated  tools  can  enable  easier  and 
more  accurate  analysis.   However,  the  right  kind  of  Infor- 
mation must  be  embedded  within  the  formalized  specification 
to  enable  computer  tools  to  ensure  consistency  [Ro77c]. 
This  Information  will  actually  be  meta-lnformat Ion  (Infor- 
mation about  Information)  and  Is  usually  included  in  the 
specification  through  the  Introduction  of  formal  notations 
or  possibly  even  a  meta-language  to  aid  in  consistency 
checking. 
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Chapter  Two 
A  NAMING  CONVENTION  TO  AID  IN  THE  CONSISTENCY  CHECKING 
OF  STRUCTURED  ANALYSIS  REQUIREMENTS  SPECIFICATIONS 

A  consistent  requirements  specification  is  a  necessity 
when  developing  a  system.   The  requirements  specification 
lays  the  groundwork  for  all  subsequent  stages.   Without  a 
strong  foundation,  it  is  unlikely  that  a  correct  solution 
can  be  completed  for  a  problem;  and  if  a  correct  solution 
is  implemented,  it  is  likely  that  the  cost  of  development 
will  be  higher  than  necessary.   Therefore,  by  reducing  the 
number  of  errors  in  a  system  early  in  the  development  pro- 
cess, the  probability  of  a  correct  solution,  and  a  solution 
with  less  cost,  is  increased.   Consistency  checking  of 
requirements  specifications  is  one  method  of  possibly 
reducing  the  number  of  errors  in  the  implementation  of  a 
system. 

INCONSISTENCIES  WITHIN  STRUCTURED  ANALYSIS  DIAGRAMS 

In  a  Structured  Analysis  dataflow  diagram,  inconsis- 
tencies arise  within  the  data  elements  that  cross  diagram 
boundaries.   The  number  of  diagrams  in  the  specification  of 
a  complex  system  is  large.   The  diagrams  are  usually  devel- 
oped manually.   Many  different  people  each  develop  small 
pieces  of  the  system.   Combining  the  large  number  of  dia- 
grams with  current  methods  of  development  provides  ample 


-  9  - 


opportunities  for  inconsistencies  to  be  introduced  through 
miscommunication  between  developers,  or  simply  through 
slight  carelessness  in  recording  the  specification.   As  the 
system  specification  is  decomposed,  the  information  con- 
tained within  a  single  diagram  becomes  more  concrete.   Ab- 
stract names  given  to  data  elements  at  a  higher  level  in 
the  specification  will  no  longer  be  appropriate  for  the 
data  elements  at  a  lower,  less  abstract  level.   The  names 
of  data  elements  change  to  allow  more  information  to  be 
communicated.   However,  the  changes  introduced  must  be 
consistent  with  the  information  given  in  the  next  higher 
abstraction  level. 

To  enable  consistency  checking,  the  specification  must 
be  formalized  in  some  manner.   This  is  usually  done  by 
embedding  meta-inf ormat ion,  or  by  adding  notation  within 
the  existing  system.   The  meta- inf ormat ion,  or  added 
notation,  enables  consistency  checking  by  supplying  needed 
information  for  stating  intended  relationships  between  the 
various  parts  of  the  specification. 

The  consistency  checker,  whether  man  or  machine,  then 
extracts  the  information  and  analyzes  it  by  comparing  the 
information  from  the  specification  with  the  expected 
results.   In  Structured  Analysis,  the  extracted  information 
must  deal  with  how  data  elements  are  related  between 
abstraction  levels.   Any  differences  between  the  extracted 
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information  and  expected  results  indicates  possible 
problems  that  may  require  correction  or  modification. 

The  consistency  checks  to  be  performed,  will  determine 
whether  all  data  elements  have  their  appropriate  sources 
and  sinks.   This  means  that  not  only  must  a  data  element 
have  a  source  and  sink,  but  that  same  data  element  must 
logically  have  the  same  source  and  the  same  sink  at  all 
levels  of  abstraction.   As  the  data  element  is  decomposed, 
the  relationship  between  abstraction  levels  in  the 
decomposition  must  be  shown.   Therefore,  an  inconsistency 
is  one  of  two  things:   1)  different  data  element  names  at 
adjacent  abstraction  levels  for  an  identical  data  element, 
or   2)  different  sources  or  sinks  at  adjacent  abstraction 
levels  for  an  identical  data  element. 
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A  NOTATION  ENABLING  CONSISTENCY  CHECKING 

One  possible  added  notation  for  locating  the  above 
inconsistencies  is  illustrated  in  Figures  2-1  and  2-2.   The 
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notation  enables  a  consistency  checker  to  follow  the 
derivation  of  a  data  element.   An  extension  is  added  to  the 
element  name,  indicating  its  source  (where  it  is  obtained) 
and  also  its  sink  (where  it  is  used).   Figure  2-1 
illustrates  a  complete  diagram  from  a  system  specification 
in  its  original  form.   All  input,  output,  and  control 
identifiers  are  included  in  the  illustration.   Figure  2-2 
shows  the  same  basic  diagram,  with  names  removed  and 
identifier  extensions  added.   The  extensions  would  actually 
be  appended  to  the  end  of  each  data  element,  but  appear  in 
the  diagram  separately  for  clarity. 
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The   extensions   specify   the   data  element   source   and 

also  the  data  element  sink.   For  example,  the  data  element 

STUDENT  INFO  in  PRODUCE  TRANSCRIPT  begins  as  input  one  (ID 

of  this  diagram  (A2)  and  ends  as  input  one  (II)  of  activity 

ACCESS  STUDENT  RECORD  (A21).   The  extension  therefore 

becomes  A2I1/A21I1.  The  data  element  source  identifier  (the 
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extension  before  the  slash)  and  the  data  element  sink 
identifier  (the  extension  after  the  slash)  are  each  made  by 
either  concatenating  the  activity  identifier  (i.e.,  'A2') 
with  the  data  element  Identifier  (i.e.,  'II'),  or  for  data 
elements  being  split  or  joined,  from  the  arbitrarily 
assigned  split/join  identifier  (i.e.,  'S3').   Activity 
identifiers  are  taken  from  the  identifier  of  the 
source/sink  activity.   For  sources/sinks  that  cross  diagram 
boundaries,  the  activity  identifier  is  taken  from  the 
diagram  identifier.   Data  element  identifiers  are  assigned 
arbitrarily  at  the  time  of  specification  development.   The 
relative  numbering  of  data  element  identifiers  must  remain 
identical  between  abstraction  levels,  to  reduce  errors 
identified  during  consistency  checking.   Split/Join 
identifiers  are  assigned  arbitrarily  at  the  time  extensions 
are  added  to  data  element  identifiers.   For  an  exact 
explanation  of  the  method  for  adding  extensions  to  data 
elements,  see  appendix  B. 

Current  Structured  Analysis  specification  styles  allow 
for  the  logical  splitting  or  joining  of  data  elements  at 
the  diagram  boundary,  without  explicitly  specifying  the 
split  or  join.   Because  of  the  method  of  source/sink  iden- 
tification, further  formalization  is  required  within  a 
system  specification.   In  addition  to  the  extension  nota- 
tion, it  becomes  necessary  to  require  that  all  data  ele- 
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ments  crossing  diagram  boundaries  be  in  the  same  form  on 
both  sides  of  the  boundary.   Requiring  that  all  splits  and 
joins  be  explicity  specified  enables  consistency  checking. 

THE  METHOD  OF  CHECKING  FOR  CONSISTENCY 

With  the  introduction  of  the  above  notation,  it 
becomes  possible  to  check  for  consistency  within  a  require- 
ments specification.   Currently,  structured  analysis 
diagrams  are  produced  manually,  with  limited  aid  from 
automated  graphics  systems.   This  means  that  the  addition 
of  the  notation  and  the  extraction  of  the  information 
required  for  checking  must  also  be  done  manually.   The 
information  must  be  gathered  and  arranged  manually.   To 
enable  automated  consistency  checking,  the  information  must 
be  combined  into  a  textual  diagram  description.   The 
textual  diagram  description  contains  all  necessary  informa- 
tion required  by  the  consistency  checker. 

The  diagram  description  can  be  broken  down  into  four 
basic  parts:   the  IOC  section,  the  activity  section,  the 
split  section,  and  the  join  section.   The  IOC  section 
specifies  all  inputs,  outputs,  and  controls  that  cross  the 
diagram  boundary  of  a  detail  diagram  to  the  abstraction 
level  directly  above  the  diagram.   The  activity  section 
specifies  all  inputs,  outputs,  and  controls  that  cross  the 
diagram  boundary  to  the  abstraction  level  directly  below 
the  diagram.   The  split  section  and  join  section  supply 
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information  for  connecting  data  elements  between  the  other 
two  sections.   Figure  2-3  at  the  end  of  the  chapter  shows  a 
completed  diagram  description  for  the  diagrams  in  figures 
2-1  and  2-2. 

DATA  SOURCES  AND  SINKS 

When  diagram  descriptions  have  been  completed,  the 
consistency  checking  can  begin.   Two  types  of  checking  must 
be  performed:   inter-diagram  checks,  and  also  intra-diagram 
checks.   The  inter-diagram  checks  ensure  consistency  be- 
tween various  levels  within  the  diagram  hierarchy.   The 
intra-diagram  checks  ensure  consistency  within  a  single 
diagram. 

Inter-diagram  consistency  checking  must  be  performed 
for  each  activity  in  the  diagram  hierarchy  that  is 
decomposed  in  a  lower-level  detail  diagram.   Data  sources 
are  extracted  from  each  activity  and  its  related  detail 
diagram.   The  possible  data  sources  are  inputs  and  controls 
to  the  activity,  and  the  outputs  from  the  detail  diagram. 
For  each  source,  the  extension  is  used  to  locate  the 
appropriate  data  sink.   The  possible  data  sinks  are  inputs 
and  controls  to  the  detail  diagram,  and  outputs  from  the 
activity.   The  extension  gives  the  diagram  identifier  and 
data  element  identifier.   If  a  data  element  is  found  in  the 
appropriate  position,  the  data  elements  are  compared. 
Non-identical  data  element  names  signify  inconsistencies. 
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After  all  possible  sources  have  been  identified  and 
checked,  data  element  sinks  are  located.   All  sinks  not 
matched  to  a  data  element  source  are  additional 
i neons  istencies . 

Intra-diagram  consistency  checking  is  performed  for 
each  diagram  in  the  diagram  hierarchy.   Intra-diagram 
checks  are  easier  to  perform  than  inter-diagram  checks 
since  all  required  information  is  located  on  one  diagram. 
The  process  begins  by  extracting  data  sources.   The  pos- 
sible data  sources  are  inputs  and  controls  to  the  diagram, 
and  the  outputs  from  each  activity  in  the  diagram.   For 
each  source,  the  extension  is  used  to  locate  the 
appropriate  data  sink.   The  possible  data  sinks  are  inputs 
and  controls  to  each  activity  in  the  diagram,  and  outputs 
from  the  diagram.   Splits/Joins  are  treated  similar  to 
activities.   If  a  data  element  is  found  in  the  appropriate 
position,  the  data  elements  are  compared.   Non-identical 
data  element  names  signify  inconsistencies.   After  all 
possible  sources  have  been  identified  and  checked,  data 
element  sinks  must  be  located.   All  sinks  not  previously 
matched  to  a  data  element  source  are  additional 
i neons  istencies. 
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diagram:   PRODUCE.TRANSCRIPT 

input:   STUDENT_INF0.A2I1/A21I1 
control:   PRODUCE  COMMAND. A2C 1 /Jl 
output:   TRANSCRIPT. A2301/A201 

activity:   ACCESS_STUDENT_RECORD 

input:   STUDENT  INFO. A2I1 /A2 1 1 1 
contro 1 :   PRODUCE_COMMAND . J 1 / A2 1 C 1 
output:   STUDENT_REC0RD.A2101/A22I1 

activity:   FORMAT_TRANSCRIPT 

input:  STUDENT_REC0RD.A2101 /A22I 1 
control:  PRODUCE  COMMAND. J2/A22C1 
output:   F0RMATTe5_TRANSCRIPT.A2201/A23I1 

activity:   PRINT_TRANSCRIPT 

input:   F0RMATTED_TRANSCRIPT.A2201/A23I 1 
control:   PRODUCE  COMMAND. J2/A23C1 
output:   TRANSCRIPT. A2301/A201 

split:   PR0DUCE_C0MMAND.A2C1/J1 

output:   PR0DUCE_C0MMAND.J1/A21C1, 
PRODUCE_COMMAND . J 1 / J2 

split:   PR0DUCE_C0MMAND.J1/J2 

output:   PR0DUCE_C0MMAND.J2/A22C1, 
PRODUCE_COMMAND . J2 / A23C1 

end : 

FIGURE  2-3   DIAGRAM  DESCRIPTION  EXAMPLE 
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Chapter  Three 
CONSISTENCY  CHECKER  REQUIREMENTS  SPECIFICATION 

When  specifying  a  system,  several  basic  questions 
should  be  addressed:   1)   What  is  the  general  description 
of  the  problem  to  be  solved,   2)   Who  will  be  the  predomi- 
nant users  of  the  system,   3)   What  is  the  required  form 
for  the  system  input,   4)   What  is  the  required  form  for 
the  system  output,  and  5)   What  operational  constraints 
exist  for  the  system.   After  these  questions  have  been 
answered,  a  system  model  must  be  developed. 

GENERAL  PROBLEM  DESCRIPTION 

The  system  to  be  implemented  will  take  a  requirements 
specification  in  the  form  of  a  set  of  structured  analysis 
diagram  descriptions  and  produce  a  report  of  any  inconsis- 
tencies in  inputs,  outputs,  and  controls  that  occur  within 
the  specification.   The  consistency  checker  will  check  for 
any  data  source  that  does  not  have  appropriate  data  sinks. 
When  analyzing  a  single  diagram,  the  possible  sources  are 
diagram  inputs,  diagram  controls,  and  activity  outputs;  and 
the  possible  sinks  are  diagram  outputs,  activity  inputs, 
and  activity  controls.   When  analyzing  the  diagram  tree, 
the  possible  sources  are  activity  inputs  (taken  from  the 
parent  dia-  gram),  activity  controls  (taken  from  the  parent 
diagram),  and  diagram  outputs,  and  the  possible  sinks  are 
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activity  outputs  (taken  from  the  parent  diagram),  diagram 
Inputs,  and  detail  controls. 

INVOCATION  OF  TOOL 

The  predominant  users  of  the  consistency  checking 
system  will  be  students  in  the  Department  of  Computer 
Science  at  Kansas  State  University.   It  will  fae  used  along 
with  other  software  tools  at  the  university,  and  it  would 
therefore  be  advantageous  to  operate  similar  to  other 
available  software  tools.   With  this  in  mind,  the  invoca- 
tion process  should  be  similar  to  other  applications  on  the 
targeted  hardware.   The  invocation  includes  the  mechanisms 
for  obtaining  input  and  directing  output  from  the  consis- 
tency checker. 

DEFINITION  OF  INPUT 

The  required  system  input  will  be  a  set  of  textual 
structured  analysis  diagram  descriptions.   Each  diagram 
description  includes  all  information  required  by  the 
consistency  checker.   This  information  states  the  name  of 
the  diagram;  a  list  of  all  diagram  inputs,  outputs,  and 
controls;  a  list  of  all  activities  within  the  diagram, 
along  with  the  inputs,  outputs,  and  controls  to  each 
activity;  and  also  a  list  of  all  splits  and  joins  of  each 
data  element  within  the  diagram.   The  exact  form  for  the 
diagram  descriptions  can  be  found  in  Appendix  A.   An 
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example  of  a  complete  diagram  description  can  be  found 
later  in  this  chapter,  and  instructions  for  description 
development  can  be  found  in  Appendix  B.   The  diagram 
description  is  in  free-format,  thus  relieving  the  user  from 
the  problem  of  errors  introduced  by  requiring  highly 
structured,  error-prone,  formatted  input. 

DEFINITION  OF  OUTPUT 

The  output  will  include  an  echo  of  the  input,  produc- 
ing a  formatted  copy,  indenting  sub-sections,  and  aligning 
columns  of  information.   For  any  error  encountered  while 
scanning  the  input  file,  an  appropriate  error  message  will 
be  issued,  indicating  the  error  encountered,  and  also  its 
location  within  the  input  file.   Also  included  in  the 
output  will  be  a  report  of  all  consistency  errors  found 
within  the  set  of  diagram  descriptions.   The  list  of  all 
possible  error  messages  are  listed  appendix  D. 

OPERATIONAL  CONSTRAINTS 

Operationally,  the  consistency  checking  system  should 
perform  in  a  manner  similar  to  other  available  tools.   The 
method  for  acquiring  system  input  and  producing  system 
output  will  therefore  be  logical  and  familiar  to  the  user. 

STRUCTURED  ANALYSIS  MODEL  OF  THE  PROPOSED  SYSTEM 

Figure  3-1  shows  the  system  described  previously  in 
the  General  Problem  Description  and  is  entitled  CONSISTENCY 
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CHECKER.   The  system  contains  three  major  activities:   SCAN 
DIAGRAM  DESCRIPTION  INPUT,  PRODUCE  DIAGRAM  DESCRIPTION 
OUTPUT,  and  PRODUCE  CONSISTENCY  REPORT.   SCAN  DIAGRAM 
DESCRIPTION  INPUT  scans  the  diagram  description  input  pro- 
ducing either  error  messages  relating  to  the  input  scan,  or 
producing  an  internal  representation  of  the  diagram 
description  that  will  be  formatted  and  sent  to  output  by 
PRODUCE  DIAGRAM  DESCRIPTION  OUTPUT.   The  internal  repre- 
sentation of  the  diagram  description  is  also  used  by 
PRODUCE  CONSISTENCY  REPORT.   This  activity  performs  the 
consistency  check  producing  appropriate  error  messages 
relating  to  the  consistency  state  of  the  diagram  descrip- 
tions.  Further  decomposition  of  the  system  leads  to  the 
specifications  in  figures  3-2  through  3-5. 
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FICURE  3-1  -  C0nSI5TEnCV  CHECKER 

Figure  3-2  describes  the  activity  SCAN  DIAGRAM 
DESCRIPTION  INPUT,  from  diagram  CONSISTENCY  CHECKER.   In 
this  diagram,  SCAN  DIAGRAM  DESCRIPTION  INPUT  is  decomposed 
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into  GET  TOKEN,  CHECK  SYNTAX,  and  STORE  TOKEN.   GET  TOKEN 
obtains  a  single  token  from  the  input,  making  it  available 
to  CHECK  SYNTAX.   For  tokens  that  are  not  within  the 
required  syntax,  the  token  location  is  noted  and  an  appro- 
priate error  message  Is  issued.   Tokens  adhering  to  the 
required  syntax  are  stored  by  STORE  TOKEN  in  an  internal 
representation  of  the  diagram  description  for  later  access 
during  consistency  checking. 
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Figure  3-3  describes  the  activity  PRODUCE  CONSISTENCY 
REPORT,  from  diagram  CONSISTENCY  CHECKER.   In  this  diagram, 
PRODUCE  CONSISTENCY  REPORT  is  decomposed  into  LINK  DESCRIP- 
TION HIERARCHY,  CHECK  INTER-DIAGRAM  CONSISTENCY,  and  CHECK 
INTRA-DIAGRAM  CONSISTENCY.   LINK  DESCRIPTION  HIERARCHY 
connects  the  descriptions  from  the  free-format  input  into  a 
tree  of  descriptions,  checking  that  a  single  description  is 
at  the  top  of  the  structure,  and  allowing  for  further 
consistency  checks.   CHECK  INTER-DIAGRAM  CONSISTENCY  checks 
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for  existing  inconsistencies  between  related  descriptions, 
with  CHECK  INTRA-DIAGRAM  CONSISTENCY  checking  for  existing 
inconsistencies  within  an  individual  description. 
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FICURE  5-3  -  PROI'liCE  COnSISTEFICV  REPORT 

Figure  3-4  describes  the  activity  CHECK  INTER-DIAGRAM 
CONSISTENCY,  from  diagram  PRODUCE  CONSISTENCY  REPORT.   In 
this  diagram,  CHECK  INTER-DIAGRAM  CONSISTENCY  is  decomposed 
into  PRODUCE  INTER-DIAGRAM  SOURCE  LIST,  PRODUCE  INTER- 
DIAGRAM  SINK  LIST,  and  DIFFERENTIATE  SOURCE/SINK  LISTS. 
PRODUCE  INTER-DIAGRAM  SOURCE  LIST  accumulates  all  entities 
crossing  a  diagram  boundary  that  are  sources  of  data. 
PRODUCE  INTER-DIAGRAM  SINK  LIST  similarly  accumulates  all 
entities  crossing  a  diagram  boundary  that  are  sinks  of 
data.   DIFFERENTIATE  SOURCE/SINK  LISTS  compares  the 
information  in  both  lists,  matching  sources  with  all 
appropriate  sinks,  identifying  all  unmatched  sources  or 
sinks,  along  with  their  locations  within  the  set  of  diagram 
descriptions. 


-  23  - 


LiriKEti 
PEJCRIFTIOnj 


-scdnninc  erms  uses 


PRODUCE 

IflTER-DIflCHftlt 

SOURCE  LIST 


I 

iriTEl;- 
DlnCRAn 
SCiUfiCE 

LIST 


PROPUCE 

iriTER-tldORfin 

SItIK  LIST 


DIFFEREriTIflTE 

SOJRCE  SiriK 

LISTS 


iriTER- 

tilA'^RAIt 

ERROR 

uses 


-* 


^  iriTER- 

DIRCRnlt 

SIRK 

LIST 


nyi 


CHECK  iriTER-tildCRHn  COnSISTEFlCV 


riCURE  J-H  -   CHECK  IftTER-HldiRflll  COnSISTEhCV 


LlhKED 

DIACRAIt 

DESCRIFTIOnS 


-scdnniric  error  nscs 


PRODUCE 

inTRA-tilhCRRH 

SOURCE  LIST 


iniRA- 

DIACRAH 

SOURCE 

LIST 


PRODUCE 

ItlTRH-DIflCRStl 

SlflK  LIST 


iniRO- 

DIRCRfin 

ERROR 

uses 


DIFFEREriTIflTE 

SOURCE  SiriK 

LISTS 


■-  inTRH- 
DIACRAn 

siriK 

LIST 


tl7-i 


CHECK  iriTRft-DMCRfltl  COflSISTEDCV 


F1 


FICURE  3-E  -  CHECK  inTRfi-DIHCRfIN  COnSISTEflCV 

Figure  3-5  describes  the  activity  CHECK  INTRA-DIAGRAM 
CONSISTENCY,  from  diagram  PRODUCE  CONSISTENCY  REPORT.   This 
activity  is  similar  to  the  one  described  in  figure  3-4, 
checking  for  inconsistencies  related  to  sources  and  sinks 
within  a  single  diagram.   The  added  notation  is  not 
actually  required  for  this  activity  since  the  inconsis- 
tencies are  introduced  within  elements  that  cross  diagram 
boundaries.   However,  this  activity  is  required  to  relate 
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all  information  contained  in  a  hierarchy  of  more  than  two 
levels . 
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Chapter  Four 
CONSISTENCY  CHECKER  DESIGN  AND  IMPLEMENTATION 

The  consistency  checker  will  take  a  requirements 
specification  in  the  form  of  a  set  of  textual  structured 
analysis  diagram  descriptions,  and  produce  a  report  of  any 
inconsistencies  in  inputs,  outputs,  and  controls  that  occur 
within  the  specification.   The  system  will  operate  similar 
to  other  available  software  tools  in  the  Department  of 
Computer  Science  at  Kansas  State  University.   Input  to  the 
system  will  be  obtained  from  standard  input,  and  the  output 
will  be  directed  to  standard  output.   The  system  begins  by 
parsing  the  free-format  input,  extracting  and  storing  the 
required  input,  output,  and  control  information  from  the 
diagram  descriptions.   If  an  error  is  encountered  while 
parsing  the  input,  the  error  and  its  location  within  the 
input  will  be  identified.   If  the  file  is  successfully 
parsed,  a  formatted  echo  of  the  input  is  produced.   The 
parser  will  not  be  case  sensitive,  but  when  the  input  is 
echoed,  the  diagram  description  keywords  will  be  In 
lower-case,  with  user  defined  identifiers  in  upper  case. 
When  the  echo  of  input  is  complete,  the  consistency  checker 
will  link  the  diagrams  into  a  tree,  checking  inter-diagram 
consistency,  and  then  intra-diagram  consistency. 
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CONSISTENCY  CHECKER  SYSTEM  HIERARCHY 

System  hierarchy  is  outlined  in  figure  4-1.   The 
control  structure  can  be  broken  down  into  three  major 
portions:   DIAGRAM  DESCRIPTION  PARSER,  PRINT  DIAGRAM 
DESCRIPTION,  and  MAKE  CONSISTENCY  CHECKS. 
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DIAGRAM  DESCRIPTION  PARSER  will  be  implemented  using  a 
recursive-descent  process,  making  calls  to  GET  TOKEN  and 
PRINT  TOKEN.   GET  TOKEN  scans  the  input  stream  for  tokens, 
where  tokens  are  delimited  by  white  space,  or  where  appro- 
priate, by  commas  or  colons.   PRINT  TOKEN  changes  the 
internal  storage  representation  of  a  token  into  a  form 
suitable  for  printing. 

PRINT  DIAGRAM  DESCRIPTION  will  print  the  free-form 
input  in  a  more  structured  form.   When  printed,  all 
description  keywords  will  be  printed  in  lower  case,  with 
all  user-defined  identifiers  in  upper  case.   PRINT  DIAGRAM 
DESCRIPTION  also  makes  calls  to  PRINT  TOKEN. 
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MAKE  CONSISTENCY  CHECKS  will  control  the  consistency 
checking  activities,  making  calls  to  INTER-DIAGRAM  CHECKS, 
and  INTRA-DIAGRAM  CHECKS.   INTER-DIAGRAM  CHECKS  makes 
consistency  checks  of  the  whole  diagram  tree,  identifying 
existing  inconsistencies  in  relationships  between  diagrams. 
INTRA-DIAGRAM  CHECKS  makes  consistency  checks  of  a  single 
diagram,  identifying  existing  inconsistencies  within  that 
diagram.   Both  INTER-DIAGRAM  CHECKS  and  INTRA-DIAGRAM 
CHECKS  make  calls  to  PRINT  TOKEN. 

CONSISTENCY  CHECKER  IMPLEMENTATION 

The  implementation  of  the  consistency  checker  will  be 
on  a  VAX  11/780  computer  operating  under  UNIX,  at  Kansas 
State  University,  Department  of  Computer  Science.   The 
consistency  checker  will  be  implemented  using  Pascal. 

The  consistency  checker  will  expect  input  to  be  direc- 
ted from  standard  input,  and  will  direct  all  output  to 
standard  output.   The  checker  can  be  invoked,  recieving  all 
input  (terminated  by  ctrl-D)  from  the  terminal  and  direc- 
ting all  output  to  the  terminal,  by  the  command 

check 
The  checker  can  be  invoked,  receiving  all  input  from  an 
external  file  and  directing  all  output  to  the  terminal,  by 
the  command 

check  <  infile 
The  checker  can  be  invoked,  receiving  all  input  from  an 
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external  file  and  directing  all  output  to  a  separate 
external  file,  by  the  command 

check  <  infile  >  outfile 
No  other  options  are  available  at  invocation.   Error 
messages  are  outlined,  with  explanations,  in  appendix  D. 

DESCRIPTION  OF  ALGORITHMS  FOR  CHECKING  CONSISTENCY 
Two  types  of  consistency  checks  must  be  made: 
inter-diagram  checks  and  intra-diagram  checks.  The  inter- 
diagram  checks  ensure  consistency  between  various  levels 
within  the  diagram  hierarchy.   The  intra-diagram  checks 
ensure  consistency  within  a  single  diagram.   Each  diagram 
must  be  checked  for  consistency.   Inter-diagram  checking  is 
performed  first,  followed  by    intra-diagram  checking. 

Inter-diagram  consistency  checking  is  performed  for 
each  activity  in  the  diagram  hierarchy  that  is  decomposed 
in  a  lower-level  detail  diagram.   The  process  begins  by 
extracting  data  sources  from  the  activity  and  its  related 
detail  diagram.   The  possible  data  sources  are  inputs  and 
controls  to  the  activity,  and  the  outputs  from  the  detail 
diagram.   For  each  source  placed  in  this  source  list,  the 
extension  is  used  to  locate  the  appropriate  data  sink.   The 
possible  data  sinks  are  inputs  and  controls  to  the  detail 
diagram,  and  outputs  from  the  activity.   The  extension 
gives  the  diagram  identifier  and  data  element  identifier. 
If  a  data  element  is  found  in  the  appropriate  position,  the 
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data  elements  are  compared.   Non- ident ical  data  element 
names  signify  inconsistencies,  which  are  identified  as 
errors.   The  location  of  each  identified  inconsistency  is 
then  printed  for  the  user.   After  all  possible  sources  have 
been  identified  and  checked,  data  element  sinks  are 
located.   All  sinks  not  previously  matched  to  a  data  ele- 
ment source  are  identified  as  additional  inconsistencies, 
with  their  locations  printed  for  the  user. 

Intra-diagram  consistency  checking  is  performed  for 
each  diagram  in  the  diagram  hierarchy.   Intra-diagram 
checks  are  easier  to  perform  than  inter-diagram  checks 
since  all  required  information  is  located  on  one  diagram. 
The  process  begins  by  extracting  data  sources.   The  pos- 
sible data  sources  are  inputs  and  controls  to  the  diagram, 
and  the  outputs  from  each  activity  in  the  diagram.   For 
each  source  placed  in  this  source  list,  the  extension  is 
used  to  locate  the  appropriate  data  sink.   The  possible 
data  sinks  are  inputs  and  controls  to  each  activity  in  the 
diagram,  and  outputs  from  the  diagram.   Splits/Joins  are 
treated  similar  to  activities.   If  a  data  element  is  found 
in  the  appropriate  position,  the  data  elements  are  com- 
pared.  Non-identical  data  element  names  signify  incon- 
sistencies, which  are  identified  as  errors.   The  location 
of  each  identified  inconsistency  is  then  printed  for  the 
user.   After  all  possible  sources  have  been  identified  and 
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checked,  data  element  sinks  are  located.   All  sinks  not 
previously  matched  to  a  data  element  source  are  identified 
as  additional  inconsistencies,  with  their  locations  printed 
for  the  user. 
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Chapter  Five 
CONCLUSIONS 

Requirements  specifications  are  the  basis  for  develop- 
ing a  system.   The  requirements  specification  defines  the 
problem  and  outlines  the  characteristics  (including  con- 
straints) of  a  correct  solution.   The  requirements  specifi- 
cation must  answer  questions  about  the  system,  but  an 
inconsistent  specification  is  unable  to  do  this  because  the 
specification  contains  contradictions.   The  requirements 
specification  should  be  analyzable  for  consistency,  with 
mechanical  analysis  being  advantageous  since  automated 
tools  can  enable  easier  and  more  accurate  analysis. 

Structured  analysis  diagrams  are  a  graphic  system  for 
concisely  specifiying  requirements  of  large  scale  systems. 
However,  the  abstraction  process  that  gives  structured 
analysis  much  of  its  power  also  allows  inconsistencies  in 
naming  information  at  different  abstraction  levels.  Addi- 
tional information  must  be  embedded  within  the  structured 
analysis  specification  to  enable  computer  tools  to  ensure 
consistency.   In  structured  analysis,  this  embedded 
information  can  be  in  the  form  of  extensions  to  data 
element  names. 

A  consistent  requirements  specification  is  a  necessity 
when  developing  a  system.   The  requirements  specification 
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lays  the  groundwork  for  all  subsequent  stages.   Without  a 
strong  foundation,  it  is  unlikely  that  a  correct  solution 
can  be  completed  for  a  problem.   By  reducing  the  number  of 
errors  in  a  system  early  in  the  development  process,  the 
probability  of  a  correct  solution,  and  a  solution  with  less 
cost,  is  increased.   Consistency  checking  of  requirements 
specifications  is  one  method  of  possibly  reducing  the 
number  of  errors  in  the  implementation  of  a  system,  and  is 
therefore  beneficial. 
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Appendix  A 
B-N-F  GRAMMAR  FOR  STRUCTURED  ANALYSIS  DIAGRAM  DESCRIPTIONS 

GENERAL  DESCRIPTION 

A  Structured  Analysis  Diagram  Description  contains 
information  related  to  the  contents  of  a  structured  anal- 
ysis diagram.   One  description  is  required  for  each  diagram 
in  the  system  model.   When  combined,  the  set  of  diagram 
descriptions  form  the  input  for  the  consistency  checker. 
The  input  can  be  free-format,  with  the  individual  tokens  in 
the  description  separated  by  white  space,  or  when  indicated 
in  the  B-N-F,  by  commas. 

The  information  in  a  diagram  description  is  derived 
from  the  related  diagram.   The  diagram  description  contains 
the  diagram  name,  all  inputs,  outputs,  and  controls  that 
cross  the  diagram  boundary,   activity  information,  and 
split/join  information.   Activity  information  includes  the 
activity  name,  and  all  inputs,  outputs,  and  controls  for 
the  activity.   Split  information  includes  the  input  to  the 
split  and  the  list  of  outputs  from  the  split.   Join  infor- 
mation includes  the  input  list  to  the  join  and  the  output 
from  the  join. 

The  amount  of  information  contained  within  a  diagram 
description  is  ultimately  restricted  by  the  rules  governing 
diagram  development  (e.g.,  the  number  of  activities  con- 
tained within  a  description  has  a  maximum  value  of  six, 
since  the  number  of  activities  within  a  diagram  is  limited 
to  six). 

SYNTAX  DESCRIPTION 


<dgm_l ist>  : := 

<dgm_desc>  !  <dgm_desc>  <dgm_list> 

<dgm_desc>  : : = 

diagram:  <act ivity_id>  <dgm_body>  end: 

<dgm_body>  : : = 

<ioc_group>  <act i vity_l ist>  <connect_l ist> 
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<  ioc_group>  : :  = 

<input_list>  <control_l ist>  <output_l ist> 

<input_l ist>  : := 

input:  <ioc_list> 

<control_l ist>  : := 

control:  <ioc_list> 

<output_l ist>  : := 

output:  <ioc_list> 

<  ioc_l ist>  : :  = 

<  id_l ist>  !  none 

<id_list>  ::= 

<connect_id>  1  <connect_id>  ,  <id_list> 

<act i V ity_l ist>  ::= 

<activity>  !  <activity>  <act i vity_l ist> 

<act  i V  ity>  : :  = 

activity:  <act i vity_id>  <ioc_group> 

<connect_l ist>  ::= 

<split_list>  <join_list> 

<spl i t_l ist>  : : = 

<split>  :  <split>  <split_list>  !  nil 

<spl it>  : := 

split:  <connect_id>  <output_l ist> 

< join_l ist>  : : = 

<join>  !  <join>  <join_list>  !  nil 

< join>  : : = 

join:  <connect_id>  <input_list> 

<activity  id>  : := 
<id> 

<connect_id>  ::= 

<id>  <extension> 
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<id>  ::= 

<alpha>  <alphanumer ic> 

<extens  ion>  : :  = 

.  <source>  /  <sink> 

<source>  : : = 

<diagrain_number>  <ioc>  <one_to_six>  ! 
s  <one_to_six>  I  j  <  one_to_six> 

<diagram_number>  ::= 

a  <one_to_six_l ist>  !  aO 

<one_to_six>  : := 

~i  T  2  ;  3  :  4  :  5  i  6 

<one_to_six_l ist>  ::= 

<one_to_six>    I    <one_to_six>    <one_to_six_l ist> 

<  ioc>    :  :  = 


<alpha>    : : = 

aiDiCi     •••     iXiyiZi 

A!B!c:...    !x:y:z:_ 

<int>    ::= 

<digit>  !  <digit>  <int> 

<digi t>  : : = 

o;i!2:3:4:5:6:7:8:9 

<alphanumeric>  ::= 

<alpha>  <alphanumer ic>  !  <digit>  <alphanumer ic>  !  nil 
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DIAGRAM  DESCRIPTION  DEVELOPMENT 

A  Structured  Analysis  Diagram  Description  contains 
information  related  to  the  contents  of  a  structured 
analysis  diagram.   One  description  is  required  for  each 
diagram  in  the  system  model.   Before  the  diagram 
description  can  be  developed,  the  diagram  must  be  complete. 
A  complete  diagram  includes  the  following: 

1>   Diagram  name, 

2)  All  data  elements  named, 

3)  All  activities  named  and  numbered, 

4)  All  diagram  inputs,  controls,  and  outputs 
numbered, 

5)  All  activity  inputs,  controls,  and  outputs 
numbered . 

6)  All  data  element  splits/joins  explicitly 
represented  within  the  diagram. 

See  [Ro77b]  for  details  on  diagram  development.   Note  that 
item  six  above  is  a  deviation  from  current  structured 
analysis  styles  so  is  not  included  in  [Ro77bl.   A  complete 
diagram  is  illustrated  in  figure  B-1.   The  exact  syntax  for 
a  diagram  description  can  be  found  in  appendix  A. 
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NUMBERING  SPLITS/JOINS 

Before  data  element  extensions  can  be  added  all 
splits/joins  must  be  numbered,  similar  to  the  numbering  of 
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diagram  inputs,  controls,  and  outputs.   All  splits  (joins) 
are  numbered  arbitrarily  beginning  with  SI  (Jl).   In  figure 
B-2,  CI  has  been  split  twice,  giving  SI  and  S2.   Note  that 
two  splits  are  not  actually  required.   Both  splits  could  be 
combined  into  one,  thus  simplifying  the  diagram 
description.   In  the  figure,  two  splits  are  used  to  conform 
to  currently  accepted  diagram  style.   For  data  elements 
being  split  into  new,  unique  data  elements  no  further 
additions  must  be  made  to  the  diagram.   This  also  applies 
to  unique  data  elements  being  joined  into  one  new,  unique 
data  element.   For  splits  and  joins  where  the  data  element 
is  the  same  on  each  branch  of  the  split  or  join,  the  name 
must  be  copied  to  each  segment  of  the  split  or  joined  data 
element.   For  the  purpose  of  reducing  diagram  clutter,   the 
data  element  name  can  simply  be  placed  at  the  location  of 
the  split  or  join,  with  the  extensions  to  be  placed  on 
individual  segments.   If  this  alternative  is  chosen,  it  is 
recommended  that  only  one  split  or  join  be  present  on  a 
data  element  of  this  type.   See  figure  B-3. 
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ADDING  DATA  ELEMENT  EXTENSIONS 

At  this  point,  all  required  parts  of  the  diagram 
should  be  numbered.   It  is  now  possible  to  begin  adding 
data  element  extensions. 

Data  element  names  are  easily  made  by  concatenating 
the  data  source  identifier  and  the  data  sink  identifier. 
The  data  source  and  data  sink  identifiers  are  made  from  a 
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combination  of  the  activity  number  of  the  source  or  sink, 
(i.e.,  A21)  and  from  the  data  element  number  (i.e.,  II)  of 
the  source  or  sink.   A  data  source  or  data  sink  identifier 
may  also  be  the  number  of  a  split  or  join  (i.e.,  SI  or  Jl). 
The  data  source  and  data  sink  identifiers  are  concatenated 
with  a  slash,  and  are  separated  from  the  data  element  name 
with  a  period.   The  process  can  best  be  shown  through 
example . 
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In  figure  B-3,  the  extensio 
STUDENT  INFO  would  be  A2I1/A21I1 
becoming  STUDENT_INFO. A2I 1 /A2 II 1 
element  is  STUDENT  INFO,  therefo 
period  becomes  STUDENT_INFO  (all 
replaced  by  underscores).  The  f 
is  made  by  combining  the  activit 
data  element,  A2,  with  the  data 
activity  number  of  the  source  is 
diagram,  since  the  data  element 
boundary,  and  the  data  element  i 
The  second  half  of  the  extension 
the  activiy  number  of  the  sink  ( 
the  data  element  number  for  that 
Combining  these  two  parts  gives 
A2I1/A21I1.  This  is  then  concat 
to  give  the  result,  STUDENT.INFO 


n  for  the  data  element 
,  with  the  final  name 

The  name  of  the  data 
re,  the  part  before  the 

blanks  within  the  name  are 
irst  half  of  the  extension 
y  of  the  source  for  the 
element  number,  II.   The 

the  identifier  of  the 
crosses  the  diagram 
s  input  one  of  the  diagram. 

is  formed  similarly  from 
which  is  activity  A21)  and 

activity  (which  is  ID. 
the  final  extension  of 
enated  with  the  first  part 
.A2I1/A21I1. 


As  a  second  example,  the  final  data  element  name  for 
the  control  to  activity  A21,  ACCESS  STUDENT  RECORD,  becomes 
PR0DUCE_C0MMAND.S1/A21C1 .   The  first  half  is  produced  by 
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replacing  all  blanks  within  the  original  data  element  name 
with  underscores.   The  second  half  is  produced  by  combining 
the  data  element  source  and  sink  identifiers.   The  source 
identifier  Is  SI,  since  it  comes  from  split  one.   The  sink 
identifier  is  A21C1,  since  it  goes  to  activity-two-one,  and 
is  control-one  to  that  activity.   Combining  the  data 
element  source  and  sink  identifiers  with  a  slash,  and 
concatenating  the  original  data  element  name  and  the 
extension  with  a  period,  the  final  data  element  name 
becomes  PR0DUCE_C0MMAND.S1 /A2 ICl . 

The  remaining  data  element  names  with  their 
appropriate  extensions  are  given  in  figure  B-3.   Remember 
that  activity  numbers  are  taken  from  different  places 
depending  on  whether  the  data  element  crosses  a  diagram 
boundary,  and  whether  the  activity  number  refers  to  the 
data  element  source  or  sink.   Sources  that  are  inputs  or 
controls  to  the  diagram  get  the  activity  number  from  the 
diagram  itself.   All  other  sources  are  outputs  from 
activities  (or  spl i ts/ jo  ins)  within  the  diagram  and  get  the 
activity  number  directly  from  that  activity  (or  directly 
from  the  spl it/ join).   Sinks  that  are  outputs  from  the 
diagram  get  the  activity  number  from  the  diagram  itself. 
All  other  sinks  are  inputs  to  activities  (or  spl its/ j o ins) 
within  the  diagram,  or  are  controls  to  activities  within 
the  diagram.   These  sinks  get  the  activity  number  directly 
from  the  activity  (or  directly  from  the  split/join). 
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DIAGRAM  DESCRIPTION  EXAMPLE  FROM  CHAPTER  ONE 

diagram:        STUDENT.DATABASE 

input:        STUDENT_INF0.A0I1/S1 
control:       CREATE_COMMAND. AOCl /AlCl , 
PRODUCE_COMMAND. A0C2/A2C1 , 
MODIFY_COMMAND.AOC3/A3C1 
output:        CREATE_MSG.A101/A001, 
TRANSCRIPT. A201/A002, 
MODI FY.MSG . A30 1 / A003 

activity:     CREATE.STUDENT 

input:       STUDENT_INF0.S1/A1I1 
control :     CREATE_COMMAND. AOCl /AlCl 
output:      CREATE_MSG.A101/A001 

activity:      PRODUCE.TRANSCRIPT 

input:       STUDENT_INF0.S1/A2I1 
control :     PRODUCE.COMMAND. AOC2/A2C1 
output:      TRANSCRIPT. A201/A002 

activity:      MODIFY.TRANSCRIPT 

input:       STUDENT_INF0.S1/A3I1 
control :     MODIFY_COMMAND. A0C3/A3C1 
output:      M0DIFY_MSG.A301/A003 

split:         STUDENT_INF0.A0I1/S1 

output:  STUDENT_INF0.S1/A1I1, 
STUDENT_INF0.S1/A2I1, 
STUDENT_I NFO . S 1 / A3I1 

end: 
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diagram:        MODIFY_TRANSCRIPT 

input:        STUDENT_INF0.A3I1/S1 
control:       MODIFY_COMMAND. A3C1 /S2 
output:        MODIFY_MSG.A3201/A301 

activity:     ACCESS_STUDENT_RECORD 

input:       STUDENT_INF0.S1/A31I1 
control:     MODIFY_COMMAND.S2/A31Cl 
output:      STUDENT_REC0RD.A3101/A32I1 

activity:      UPDATE_STUDENT_RECORD 

input:       STUDENT  RECORD. A3101 /A32I 1 , 

STUDENT_INF0.S1/A32I2 
control:     MODIFY_COMMAND.S2/A32Cl 
output:      MODIFY  MSG . A3201 /A301 , 

UPDATE5_STUDENT_REC0RD. A3201 /A33I 1 

activity:      ST0RE_STUDENT_REC0RD 

input:       UPDATED_STUDENT_REC0RD.A3201/A33I1 
control:     MODIFY_COMMAND.S2/A33Cl 
output:      NONE 

split:         STUDENT_INF0.A3I1/S1 

output:      STUDENT_INF0.S1/A31I1, 
STUDENT_INF0.S1/A32I2 

split:         M0DIFY_C0MMAND.A3C1/S2 

output:  M0DIFY_C0MMAND.S2/A31C1, 
M0DIFY_C0MMAND.S2/A32C1, 
MODI FY_C0MMAND . S2 / A33C1 

end: 
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input: 
control : 

output: 

activity: 

input: 
control 

output: 

activity: 

input : 
control 

output : 

spl it: 

output: 

end 
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CREATE_STUDENT 

STUDENT  ID.AIII/Allll 
CREATE  COMMAND. AlCl /SI 

createImsg.aiio2/aioi 
create_student_record 

student  ID.AIII/Allll 
CREATE  command. Si /A llCl 
STUDENf_RECORD.Al 101/A12I1, 
CREATE_MSG . A 11 02 / A  1 0 1 

STORE_STUDENT_RECORD 

STUDENT_REC0RD.A1 101/A12I 1 
CREATE_COMMAND . S 1 / A 1 2C 1 
NONE 

CREATE.COMMAND . A 1 C 1 /S 1 

CREATE_C0MMAND.S1/A1 ICl, 
CREATE  COMMAND. SI /A 12C1 
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diagram:  PRODUCE_TRANSCRIPT 

input:  STUDENT_INF0.A2I1/A21I1 

control:  PRODUCE_COMMAND. A2C1 /SI 

output:  TRANSCRIPT. A2301/A201 

activity:  ACCESS_RECORD 

input:  STUDENT_INF0.A2I1/A21I1 

contro 1 :  PRODUCE_COMMAND . S 1 / A2 1  CI 

output:  STUDENT_REC0RD.A2101/A22I1 

activity:  FORMAT_TRANSCRIPT 

input:  STUDENT_REC0RD.A2101/A22I1 

control :  PRODUCE.COMMAND.Sl /A22C1 

output:  F0RMATTED_TRANSCRIPT.A2201/A23I1 

activity:  PRINT_TRANSCRIPT 

input:  F0RMATTED_TRANSCRIPT.A2201/A23I1 

control:  PR0DUCE_c5mMAND.S 1 /A23C1 

output:  TRANSCRIPT. A2301/A201 

split:  PR0DUCE_C0MMAND.A2CI/S1 

output:  PRODUCE  COMMAND. SI /A2 ICl , 
PRODUCE~COMMAND . S 1 / A22C1 , 
PRODUCeIcOMMAND . S 1 / A23C1 

end: 
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ERROR  MESSAGES 

1)  ERROR:   "diagram:"  expected 

Scanning  error.   Expecting  the  keyword  "diagram:"  as 
input. 

2)  ERROR:   "end:"  expected 

Scanning  error.   Expecting  the  keyword  "end:"  as 
input . 

3)  ERROR:   "input:"  expected 

Scanning  error.   Expecting  the  keyword  "input:"  as 
input. 

4)  ERROR:   "output:"  expected 

Scanning  error.   Expecting  the  keyword  "output:"  as 
input. 

5)  ERROR:   "activity:"  expected 

Scanning  error.   Expecting  the  keyword  "activity:"  as 
input . 

6)  ERROR:   "control:"  expected 

Scanning  error.   Expecting  the  keyword  "control:"  as 
input . 

7)  ERROR:   unexpected  comma  or  keyword 

Scanning  error.   Expecting  identifier,  but  found  comma 
or  keyword. 

8)  ERROR:   no  AO  diagram 

Scanning  error.   A  diagram  description  for  the  highest 
abstraction  level  was  not  encountered  In  the  Input 
file. 
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9)   ERROR:   multiple  AO  diagrams 

Scanning  error.   More  than  one  diagram  description  for 
the  highest  abstraction  level  was  encountered  in  the 
input  file. 

10)  ERROR:   unmatched  source(s)  in  diagram 

Consistency  error.   One  or  more  source  data  elements 
were  not  matched  to  an  appropriate  sink  data  element. 

11)  ERROR:   unmatched  sinkCs)  in  diagram 

Consistency  error.   One  or  more  sink  data  elements 
were  not  matched  to  an  appropriate  source  data 
element. 
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IMPLEMENTATION  SOURCE  CODE 


program  check  ( input, output) ; 

Check  —  Program  to  check  consistency  of  a  structured 
analysis  diagram  description.   The  required  format  for 
the  input  file  is  described  in  Master's  Thesis: 

CONSISTENCY  CHECKING  OF  REQUIREMENTS  SPECIFICATIONS 
USING  STRUCTURED  ANALYSIS  DIAGRAMS 

by 

Aaron  Friesen 
Program  Completed  December  1986. 

Note:   All  input  is  taken  from  Standard  Input,  and  all 
output  is  directed  to  Standard  Output. 
********************************************************* ^ 


type 

strSO  = 
dgmptr  = 
iocptr  = 

iocrec  = 


packed  array [ 1 

"dgmrec; 

'^  iocrec; 


80] 


of  char; 

(*  diagram  info        *) 
(*  input,  output, 

control  info  *) 


record 

name  :  str80; 

next  :  iocptr; 
end;  (*  record  *) 


actptr  = 

^actrec; 

actrec  = 

record 

name    : 

str80; 

ins 

iocptr; 

ctrls 

iocptr; 

outs 

'  iocptr; 

detail 

:  dgmptr; 

(*  ioc  name 
(*  next  ioc 

(*  activity  info 


*) 
*) 

*) 


next    :  actptr; 
end;  (*  record  *) 


(* 

activity  name 

*) 

<* 

input  list 

*) 

(* 

control  list 

*} 

(* 

output  1 ist 

*) 

(* 

detail  diagram 

for  activity 

*) 

(* 

next  activity 

*) 

sjptr  = 

''sjrec; 

(* 

split,  join  info 

*) 

sjrec  = 

record 

whole  :  strSO; 

(* 

sj  name 

*) 

parts  :  iocptr; 

(* 

input/output  list 

*) 

next   :  sjptr; 

(* 

next  sj 

*) 
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*) 


dgmptr 
dgmrec 


chkptr  = 
chkrec  = 


end;  <*  record 
'^dgmrec;  ) 
record 

name 

hasparent 

ins 

ctrls 

outs 

acts 

spl its 

jo  ins 

next 
end;  (*  record 
"chkrec; 
record 

name  1  :  strSO; 

name2  :  strSO; 

kind   :  char; 

next   :  chkptr; 

end;  <*  record  *) 


StrSO; 
boolean; 
iocptr; 
iocptr; 
iocptr; 
actptr; 
sjptr; 
sjptr; 
dgmptr; 
*) 


(*  diagram  info  *) 

(*  diagram  name  *) 

(*  parent  flag  *) 

(*  input  list  *) 

(*  control  1 ist  *) 

<*  output  list  *) 

(*  activity  1 ist  *) 

(*  split  list  *) 

(*  join  list  *) 

(*  next  diagram  *) 


(*  check  list  info  *) 

<*  source/sink  name  *) 

(*  source/sink  kind  *) 
(*  next  source/sink 

to  check  *) 


var 

cccc  :  char; 

dgm  :  dgmptr; 

word  :  strSO; 

1 ine  :  integer; 


(*  global,  next 

char  in  input   *) 
<*  head  pointer 

for  diagrams    *) 
(*  temp  input 

variable       *) 
(*  current  1 ine  of 

input  file   *) 
(*  global  error  flag    *) 


error  :  boolean; 
procedure  GetWord  (var  word:str80;  var  1 ine : integer) ; 

GetWord  —  Scans  input  stream  for  one  'word.*   A  'word' 
is  defined  as  anything  delimited  by  white  space. 
Also,  a  comma  or  colon  is  assumed  to  mark  the  end  of 
a  'word.' 

word  —  'word'  being  input 

line  --  current  line  number  within  input  file  being 

scanned 
cccc  —  global  variable  of  next  input  character  to  be 

used 
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length  :  integer;   (*  length  of  input  word  *) 
function  GetCh  :  char; 

GetCh  —  Gets  a  character  from  the  input  stream, 
converting  all  white  space  to  blanks. 

cccc  —  input  character 

var  ch  :  char;   (*  temporary  input  character  *) 

begin 

if  eoln  then  line  :=  line  +  1; 

read(ch) ; 

if  ch  in  ['a' . .'z' ] 

then  ch  :=  chr(ord(ch)  -  32) 

else  if  (ch  =  tab)  or  (ch  =  chr(12))  then  ch  :=  '  '; 
GetCh  :=  ch; 
end; 

begin 

word  :=  '   '; 

length  :=  0; 

while  not  eof  and  (cccc  =  '  ' )  do  cccc  :=  GetCh; 

while  not  eof  and  (cccc  <>  ':') 

and  (cccc  <>  '  *)  and  (cccc  <>  ',')  do 
begin 

length  :=  length  +  1; 
wordt length]  :=  cccc; 
cccc  :=  GetCh; 
end;  (*  while  *) 
if  cccc  =  ' : ' 
then 
begin 

word[length+l ]  :=  cccc; 
cccc  :=  GetCh; 
end  (*  then  *) 
else  if  (length  =  0)  and  (cccc  =  ',') 
then 
begin 

word  :=  *,  *; 
cccc  :=  GetCh; 
end;  (*  then  *) 
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end;  <*  GetWord  *) 

procedure  PrintWord  (word:str80;  Iniboolean); 

PrintWord  —  Print  a  word,  dropping  all  trailing  blanks. 

word  —  'word'  being  printed 

In  —  boolean  indicating  new  line  (as  in  write  vs. 
writeln) 
********************************************************* ^ 

var  i  :  integer; 

begin 
i  :=  1; 

while  (word[i]  <>  '  ')  and  (i  <=  80)  do 
begin 

writeCwordt  i ] ) ; 
i  :=  i  +  1; 
end;  (*  while  *) 
if  In  then  writeln; 
end;  (*  PrintWord  *) 

procedure  err  (num: integer) ; 

(********************************************************* 
err  —  Print  an  error  message 

num  —  message  number 
*********************************************************) 


begin 

write ('ERROR; 
case  num  of 


'); 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

end; 


writelnC "diagram: "  expected'); 
writelnC "end: "  expected'); 
writelnCunexpected  comma  or  keyword'); 
writelnC " input: "  expected'); 
writeln( ' "output: "  expected'); 
writeln('"actlvity:"  expected'); 
writelnC "control : ■  expected'); 
writelnCno  AO  diagram'); 
writelnCmultiple  AO  diagrams'); 
write ('unmatched  source(s)  in  diagram  '); 
write ('unmatched  sink(s)  in  diagram  '); 
(*  case  *) 


-  52  - 


Appendix  E 


error  :=  true; 
end;  (*  err  *) 

function  KeyWord  (word:str80)  ;  boolean; 

Keyword  --  determine  if  the  word  is  a  keyword 
word  —  word  to  be  checked 

begin 

Keyword  :=  (word  =  'DIAGRAM:')   or  (word  =  'INPUT:')    or 

(word  =  'OUTPUT:')    or  (word  =  'CONTROL:')  or 

(word  =  'ACTIVITY:')  or  (word  =  'SPLIT:')    or 

(word  =  'JOIN:')      or  (word  =  'END:')      or 

(word  =  ',  '); 

end;  (*  KeyWord  *) 

procedure  GetDgm  (var  dgm:dgmptr;  var  word:str80; 

var  1 ine : integer) ; 

(********************************************************* 
GetDgm  —  Get  a  diagram  from  the  input  stream 

dgm  —  diagram  pointer 

word  --  next  word  to  be  used  from  input 
line  —  current  line  number  of  input  file 
*********************************************************) 

label  9999; 

procedure  GetlOC  (var  ioc:iocptr;  var  word:str80; 

var  1 ine : integer); 

(********************************************************* 
GetlOC  —  get  an  IOC  portion  from  the  input  stream 

ioc  --  ioc  pointer 

word  —  next  word  to  be  used  from  input 
line  —  current  line  number  of  input  file 
*********************************************************) 

begin 

if  KeyWord(word) 
then  err(3) 
else 
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begin 

new( ioc) ; 
with  100*^  do 
begin 

name  :=  word; 
next  :=  nil; 
end;  <*  while  *) 
GetWord(word,  line); 
if  word  =  ',  ' 
then 
begin 

GetWord(word,  line); 
GetIOC(  ioc'*. next,  word,  line); 
end;  (*  then  *) 
end;  (*  else  *) 
end;  (*  GetlOC  *) 

procedure  GetBox  (var  actractptr;  var  word:str80; 

var  1 ine : integer); 

GetBox  —  get  a  box  portion  from  the  input  stream 

box  --  box  pointer 

word  --  next  word  to  be  used  from  input 
line  --  current  line  number  of  input  file 
*********************************************************) 

label  9999; 

begin 

if  KeyWord(word) 
then  err(3) 
else 
begin 

new(act) ; 
with  act*  do 
begin 

name  :=  word; 
ins  :=  nil ; 
ctrls  :=  nil; 
outs  :=  nil; 
detail  :=  nil; 
next  :=  nil; 
end;  (*  with  *) 
GetWordCword,  line); 
if  word  =  'INPUT:' 
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then 
begin 

GetWord(word,  line); 
GetlOCCacf.  ins,  word,  line); 
if  error  then  goto  9999; 
if  word  =  'CONTROL:' 
then 
begin 

GetWordCword,  line); 
GetlOCCacf.ctrls,  word,  line); 
if  error  then  goto  9999; 
if  word  =  'OUTPUT:' 
then 
begin 

GetWord(word,  line); 
GetIOC(act'^.outs,  word,  line); 
if  error  then  goto  9999; 
end  (*  then  *) 
else  err(5); 
end  (*  then  *) 
else  err(7); 
end  (*  then  *) 
else  err(4); 
if  not  error  and  (word  =  'ACTIVITY:') 
then 
begin 

GetWordCword,  line); 
GetBox(act*.next,  word,  line); 
end;  (*  then  *) 
end;  (*  else  *) 
9999: 
end;  <*  GetBox  *) 

procedure  GetSplit  (var  split:sjptr;  var  word:str80; 

var  1 ine : integer) ; 

GetSplit  —  get  a  split  portion  from  the  input  stream 

split  —  split  pointer 

word  —  next  word  to  be  used  from  input 
line  --  current  line  number  of  input  file 
**********************************************************) 

begin 

if  KeyWord<word) 
then  err<3) 
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else 
begin 

new(spl it) ; 
with  split*  do 
begin 

whole  :=  word; 
parts  :=  nil; 
next  :=  nil; 
end;  (*  with  *) 
GetWord(word,  line); 
if  word  =  'OUTPUT:' 
then 
begin 

GetWord(word,  line); 
GetlOCCspl  if. parts,  word,  line); 
end  (*  then  *) 
else  err(5); 
end;  (*  else  *) 
if  not  error  and  (word  =  'SPLIT:') 
then 
begin 

GetWord(word,  line); 
GetSpl it(spl it^.next,  word,  line); 
end;  (*  then  *) 
end;  <*  GetSpl it  *) 

procedure  GetJoin  (var  join:sjptr;  var  word:str80; 

var  1 ine: integer); 

GetJoin  --  get  a  join  portion  from  the  input  stream 

join  —  join  pointer 

word  --  next  word  to  be  used  from  input 

line  --  current  line  number  of  input  file 

begin 

if  KeyWord(word) 
then  err<3) 
else 
begin 

new( join) ; 
with  join*  do 
begin 

whole  :=  word; 
parts  :=  nil; 
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next  :=  nil; 
end;  (*  with  *) 
GetWord(word,  line); 
if  word  =  'INPUT:' 
then 
begin 

GetWord(word,  line); 
GetIOC(  join''. parts,  word,  line) 
end  <*  then  *) 
else  err(5); 
end;  <*  else  *) 
if  not  error  and  (word  =  'JOIN:') 
then 
beg  in 

GetWord(word,  line); 
GetJoinC join^.next,  word,  line); 
end;  (*  then  *) 
end;  (*  GetJoin  *) 

begin 

if  KeyWord(word) 
then  err(3) 
else 
begin 

new(dgm) ; 
with  dgm''  do 
begin 

name  :=  word; 
hasparent  :=  false; 
ins  :=  nil; 
ctrls  :=  nil; 
outs  :=  nil ; 
acts  :=  nil; 
spl its  : =  nil ; 
joins  :=  nil ; 
next  :=  nil; 
end;  (*  with  *) 
GetWord(word,  line); 
if  word  =  'INPUT:' 
then 
begin 

GetWord(word,  line); 
GetlOCCdgm". ins,  word,  line); 
if  error  then  goto  9999; 
if  word  =  'CONTROL:' 
then 
begin 
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GetWord<word,  line); 
GetIOC(dgm'".ctrls,  word,  line); 
if  error  then  goto  9999; 
if  word  =  'OUTPUT:' 
then 
begin 

GetWord(word,  line); 
GetIOC(dgm''.outs,  word,  line); 
if  error  then  goto  9999; 
if  word  =  'ACTIVITY:' 
then 
begin 

GetWord(word,  line); 
GetBox(dgm^.acts,  word, 

1 ine) ; 
if  error  then  goto  9999; 
if  word  =  'SPLIT:' 
then 
begin 

GetWordCword,  line); 
GetSpl  it(dgm'^.spl  its, 
word,  line); 
end;  (*  then  *) 
if  error  then  goto  9999; 
if  word  =  'JOIN:' 
then 
begin 

GetWord<word,  line); 
GetJoinCdgm''.  joins, 
word,  line); 
end;  (*  then  *) 
if  word  =  'END:' 

then  GetWord(word,  line) 
else  err(2); 
end  (*  then  *) 
else  err(6); 
end  (*  then  *) 
else  err(5); 
end  (*  then  *) 
else  err<7); 
end  <*  then  *) 
else  err(4); 
end;  (*  else  *) 
if  word  =  'DIAGRAM:' 
then 
begin 

GetWord<word,  line); 
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GetDgm(dgm''.next,  word,  line); 
end  (*  then  *) 
else  if  (word  <>  '   ')  and  not  error  then  err(l); 

9999  : 

end;  (*  GetDgm  *) 

procedure  PrintDgms  (dgm  :  dgmptr); 

PrintDgms  —  print  the  diagrams  from  the  input  file 
dgm  --  diagram  pointer 

procedure  PrintlOC  ( ioc: iocptr) ; 

PrintlOC  —  print  the  IOC  portion  of  the  diagram 

IOC  —  IOC  pointer 

********************************************************* ^ 

begin 

while  ioc  <>  nil  do 
beg  in 

PrintWordC  ioc" .name, false) ; 
ioc  :=  ioc'*. next; 
if  ioc  =  nil 
then  writeln 
else 
begin 

writelnC,'); 
writeCtab,  tab); 
end;  <*  else  *) 
end;  (*  while  *) 
end;  (*  PrintlOC  *) 

procedure  PrintBox  (act lactptr) ; 

(********************************************************* 
PrintBox  --  print  the  Box  portion  of  the  diagram 

box  —  box  pointer 
*********************************************************) 

begin 
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while  act  <>  nil  do 
begin 

writeln; 

writeC*  activity:',  tab); 
PrintWord (act*. name, true); 
writeln; 

writeC     input:',  tab); 
PrintlOCCacf.  ins); 
writeC     control:',  tab); 
Print IOC(act*.ctrls); 
writeC     output:',  tab); 
PrintIOC(act*.outs); 
act  :=  acf^.next; 
end;  (*  while  *) 
end;  (*  PrintBox  *) 

procedure  PrintSJ  (sj:sjptr;  infol,  inf o2 : strSO) ; 

PrintSJ  —  print  the  SJ  portion  of  the  diagram 

sj  --  sj  pointer 
*********************************************************) 

begin 

while  sj  <>  nil  do 
begin 

writeln; 

writeC   '); 

PrintWord( inf ol , false ) ; 

write (tab) ; 

PrintWord(sj'^.  whole,  true); 

writeln; 

writeC     '); 

Pr intWord( inf o2, false) ; 

wr ite(tab) ; 

PrintIOC(sj''.  parts); 

sj  :=  sj^.next; 
end;  (*  while  *) 
end;  (*  PrintSJ  *) 

begin 

while  dgm  <>  nil  do 
begin 

writeln; 

wr i teCdiagram: ' ,  tab); 

Pr  i  ntWord(dgra'^ .  name ,  true  ) ; 
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wr iteln; 

writeC   input:*,  tab); 
PrintIOC(dgm''.  ins); 
writeC   control:',  tab); 
PrintIOC(dgm''.ctrls); 
writeC   output:',  tab); 
Pr int IOC (dgm^. outs); 
PrintBoxCdgm^.acts); 

PrintSJ(dgm". splits, 'split:  ', 'output:  '); 
PrIntSJCdgm". joins,' join:  ', 'input:  '); 
wr iteln; 

writelnC 'end: ' ); 
writeln; 

dgm  :=  dgm*.next; 
end;  (*  while  *) 
end;  (*  PrintDgm  *) 

procedure  CheckConsistency  (dgm:dgmptr) ; 

CheckConsistency  —  Check  consistency  of  the  diagrams 
dgm  —  diagram  pointer 

var 

d,  parent  :  dgmptr; 
a  :  actptr; 
count  :  integer; 

procedure  MakeDgmLink  (dgm:dgmptr;  act:actptr); 

MakeDgmLink  —  link  the  diagrams  into  a  tree  structure 

dgm  —  diagram  pointer 
act  —  activity  pointer 
*********************************************************) 

begin 

while  (dgm'^.next  <>  nil) 

and  (acf^.name  <>  dgm'^.name)  do 
dgm  :=  dgm'". next; 
if  act*. name  =  dgm*. name 
then 
begin 

act*. detail  :=  dgm; 
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dgm'^  .hasparent  :=  true; 
end;  (*  then  *) 
end;  <*  MakeDgmLink  *) 

procedure  Append  (name : strSO;  klnd:char; 

var  1 ist:chkptr); 

Append  —  append  the  input  name  to  the  list 

name  —  input  name  to  be  appended 
kind  --  kind  of  name  being  added  to  the  list 
list  —  list  of  names 
********************************************************* ^ 

begin 

newd  isf^.next); 

1 ist  :=  1 ist^.next; 

list*. next  :=  nil; 

list^.namel  :=  name; 

list''.name2  :=  name; 

1 ist*. kind  :=  kind; 
end;  <*  Append  *) 

procedure  MakeList  (ioc:iocptr;  kind:char; 

var  1 ist:chkptr) ; 

(********************************************************* 
MakeList  —  build  the  list  of  source/sink  information 

ioc  —  IOC  pointer 

kind  —  kind  of  item  being  added  to  the  list 
list  --  list  of  sources/sinks 
*********************************************************) 

begin 

while  ioc  <>  nil  do 
begin 

if  ioc*. name  <>  'NONE' 

then  Append ( ioc* .name ,k ind, 1 ist); 
ioc  :=  ioc*. next; 
end;  <*  while  *) 
end;  (*  MakeList  *) 

function  FindAndDelete  (name:str80; 

var  1 ist:chkptr) rboolean; 
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var 

current,  back  :  chkptr; 
found  :  boolean; 

begin 

found  :=  false; 
back  :=  list; 
current  :=  list". next; 

while  (current  <>  nil)  and  not  found  do 
if  current ".name 2  =  name 
then 
begin 

back". next  :=  current". next; 
dispose (current); 
current  :=  nil; 
found  :=  true; 
end  (*  then  *) 
else 
begin 

back  :=  current; 
current  :=  current" .next; 
end;  (*  else  *) 
FindAndDelete  :=  found; 
end;  (*  FindAndDelete  *) 

procedure  PrintList  ( 1 ist ichkptr) ; 

(********************************************************* 
PrintList  --  Print  the  names  of  the  items  contained 
within  the  input  list. 

list  —  list  to  be  printed 
*********************************************************) 


begin 

if  list  <>  nil 
then 
begin 
case 
'  i' 
'o' 
'c' 
's' 
'J' 
end; 


list". kind  of 
:  write(tab, 
:  write (tab, 
:  write(tab, 
:  write(tab, 
:  write(tab, 

(*  case  *) 


' ( input) 
* (output) 
* (control ) 
'(split) 
' ( jo  in) 


PrintWordd  ist ".name  1, true); 
PrintListd  ist". next); 
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end;  <*  then  *) 
end;  <*  PrintList  *) 

procedure  CheckWithin  (dgmrdgmptr) ; 

CheckWithin  —  Check  the  consistency  of  information 
that  is  within  a  diagram  description. 

dgm  —  diagram  pointer 

var 

sources,  sinks  :  chkptr; 
tempsource,  tempsink  :  chkptr; 
back  :  chkptr; 
a  :  actptr; 
sj  :  sjptr; 

begin 

if  dgm  <>  nil 
then 
begin 

new(sources) ; 
sources'". next  :=  nil; 
new(sinks) ; 
sinks'^.next  :=  nil; 
tempsource  :=  sources; 
tempsink  :=  sinks; 

MakeListCdgm'".  ins,  M  ' ,  tempsource) ; 
MakeList(dgm^.ctrls, 'c' , tempsource) ; 
MakeList  (dgm'".  outs,  'o' ,  temps  ink); 
a  ;=  dgm'". acts; 
while  a  <>  nil  do 
begin 

MakeListCa*. ins, ' i' , temps  ink); 
MakeListCa^.ctrls, 'c' , temps  ink); 
MakeList(a'".outs,  'o' ,  tempsource)  ; 
a  :=  a'". next; 
end;  (*  while  *) 
s j  : =  dgm" .spl its; 
while  sj  <>  nil  do 
begin 

Append(sj'".  whole,  's' ,  temps  ink); 
MakeListCsj^.parts, 's' , tempsource) ; 
sj  :=  sj'^.next; 
end;  <*  while  *) 
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sj  :=  dgm'^. joins; 
while  sj  <>  nil  do 
begin 

Append(sj''.whole,' j*,tempsource); 
MakeList  (s  j ''.parts, 'j',  temps  ink); 
sj  :=  sj'^.next; 
end;  (*  while  *)  I 

back  :=  sources; 
tempsource  :=  sources* .next; 
while  tempsource  <>  nil  do 
begin 

i  f  F  i ndAndDe 1 e te ( te mpsource * . name  2 , s  i nks ) 
then 
begin 

back''. next  :=  tempsource''. next; 
dispose (tempsource) ; 
tempsource  :=  back; 
end;  (*  then  *) 
back  :=  tempsource; 
tempsource  :=  tempsource*. next; 
end; 
if  sources". next  <>  nil 
then 
begin 

err( 10); 

Pr int Word (dgm*. name, true) ; 
PrintLi St (sources ".next) ; 
end;  (*  then  *) 
if  sinks*. next  <>  nil 
then 
begin 

err( 11); 

PrintWord(dgm*. name, true); 
PrintList(si nks*. next); 
end;  (*  then  *) 
a  :=  dgm*.acts; 
while  a  <>  nil  do 
begin 

Check Within(a*. detail ); 
a  :=  a*. next; 
end;  (*  while  *) 
end;  (*  then  *) 
end;  (*  CheckWithin  *) 

procedure  CheckBoundary  (dgm:dgmptr); 

(********************************************************* 
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CheckBoundary  —  Check  the  consistency  of  information 
that  crosses  diagram  boundaries. 

dgm  —  diagram  pointer 

var  a  :  actptr; 

procedure  RemoveLast  (wordin:str80;  var  wordout :str80) ; 

RemoveLast  —  Removes  the  last  half  of  the  extension 
on  an  IOC  item 

wordin  --  the  original  form  of  the  IOC  to  be  updated 
wordout  --  the  IOC  in  its  updated  form 

var 

i,  j  :  integer; 

begin 

i  :=  80; 

while  (wordinCil  <>  '/')  and  (i  >  1)  do 

i  :=  i  -  1 ; 
i  f  wordinC  i ]  =  ' /' 
then 

for  j  :=  i  to  80  do  wordinlj]  :=  '  '; 
wordout  :=  wordin; 
end;  <*  RemoveLast  *) 

procedure  RemoveFirst  <wordin:str80;  var 
wordout:str80) ; 

RemoveFirst  —  Removes  the  first  half  of  the 
extension  on  an  IOC  item 

wordin  --  the  original  form  of  the  IOC  to  be  updated 
wordout  —  the  IOC  in  its  updated  form 

var 

i,  j,  k,  n  :  integer; 

begin 

i  :=  80; 
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while  (wordinCi]  =  '  ')  and  (i  >  1)  do 

i  :=  i  -  1 ; 
if  wordint  i  +  1 ]  =  '  ' 
then 
begin 

i  *  ^  i  ^  1  * 

while  (wordinCj]  <>  '/')  and  (j  >  1 ) -do 

J  :=  J  -  I; 
if  wordinl j ]  =  ' /' 
then 
begin 

k  *  =  i    ~    1  * 

while  (wordintk]  <>  '.')  and  (k  >  1)  do 

k  :=  k  -  1; 
if  wordinCk]  =  '.' 
then 
begin 

for  n  :=  1  to  i  -  j  do 

wordin[k+n]  :=  wordintj+n); 
for  n  :=  k  +  i  -  j  +  1  to  i  do 
wordinCn]  :=  '  '; 
end;  (*  then  *) 
end;  (*  then  *) 
end;  <*  then  *) 
wordout  :=  wordin; 
end;  (*  RemoveFirst  *) 

procedure  MakeCheck  (act:actptr;  parent :dgmptr) ; 

MakeCheck  —  Performs  the  actual  consistency  check 
of  the  information  that  crosses  diagram  boundaries. 

act  --  activity  pointer 

parent  —  diagram  pointer  pointing  to  the  parent 
diagram 

var 

sources,  sinks  :  chkptr; 
tempsource,  temps  ink  :  chkptr; 
back  :  chkptr; 

procedure  AddemSources  (ioc:iocptr;  kind;char; 

var  1 ist:chkptr) ; 
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AddemSources  --  Build  a  source  list  from  the 

detail  diagram.   Before  the  sources  are  added  to 
the  list,  remove  the  first  half  of  the  extension. 

ioc  —  ioc  pointer 

kind  —  kind  of  item  being  added  to  the  list 

list  —  list  of  sources 

begin 

while  ioc  <>  nil  do 
begin 

if  ioc'^.name  <>  'NONE' 
then 
begin 

Append ( ioc" .name, kind, 1 ist); 
case  kind  of 

'i'  :  RemoveFirstd  isf.name  1 , 

1 ist*.name2); 
'o'  :  RemoveLastd  isf^.name  1 , 

1  isf^  .name2) ; 
'c*  :  RemoveFirstd  isf^.name  1 , 

1 ist* .name2) ; 
end;  (*  case  *) 
end;  (*  then  *) 
ioc  :=  ioc". next; 
end;  (*  while  *) 
end;  (*  AddemSources  *) 

procedure  AddemSinks  (iocriocptr;  kind:char; 

var  1 ist rchkptr) ; 

AddemSinks  --  Build  a  sink  list  from  the  detail 
diagram.    Before  the  sinks  are  added  to  the 
list,  remove  the  last  half  of  the  extension. 

ioc  —  ioc  pointer 

kind  —  kind  of  item  being  added  to  the  list 

list  —  list  of  sinks 

begin 

while  ioc  <>  nil  do 
begin 

if  ioc". name  <>  'NONE' 
then 
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begin 

Append ( ioc'^.name,kind,  1  ist); 
case  kind  of 

M'    :    RemoveLastdisf.namel, 

1 ist*.name2); 
'o'    :    RemoveFirstd  isf.namel, 

1 ist*.name2) ; 
*c'    :    RemoveLastd  isf^.name  1 , 

1 ist*.name2) ; 
end;    (*  case    *) 
end;    (*   then   *) 
ioc    :=    ioc^.next; 
end;    (*   while    *) 
end;    <*   AddemSinks    *) 

begin 

if  act*. detail  <>  nil 
then 
begin 

newCsources) ; 
sources'^. next  :=  nil; 
new(sinks) ; 
sinks'". next  :=  nil; 
tempsource  :=  sources; 
tempsink  :=  sinks; 

AddemSourcesCact*. ins, ' i ' , tempsource) ; 
AddemSourcesCact^.ctrls, 'c' , tempsource) ; 
AddemSources (act ''.outs,  'o' ,  tempsource)  ; 
Adde mS i nk s ( act '". detail'",  ins, '  i ' ,  tempsink) ; 
AddemSinksCacf.detai  I'^.ctrls,  'c' ,  tempsink) ; 
AddemSinksCacf".  detail '".outs,  'o' ,  tempsink); 
back  :=  sources; 
tempsource  :=  sources'". next; 
while  tempsource  <>  nil  do 
begin 

if  F i ndAndDe  1  e te ( tempsource '" . name 2 , s inks ) 
then 
begin 

back'". next  :=  tempsource'". next; 
dispose (tempsource ) ; 
tempsource  :=  back; 
end;  (*  then  *) 
back  :=  tempsource; 
tempsource  :=  tempsource'". next; 
end;  (*  where  *) 
if  sources'". next  <>  nil 
then 
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begin 

err( 10); 

Pr  int Word ( parent '*. name,  false)  ; 
writeC  in  activity  '); 
PrintWord(  act '".name,  true); 
PrintLi St (sources". next) ; 
end;  (*  then  *) 
if  sinks'^. next  <>  nil 
then 
begin 

err( 11); 

PrintWord(  act ''.name,  true)  ; 
PrintList(  sinks'^,  next); 
end;  (*  then  *) 
end;  <*  then  *) 
end;  (*  MakeCheck  *) 

begin 

if  dgm  <>  nil 
then 
begin 

a  :=  dgm'^^.acts; 
whi le  a  <>  nil  do 
begin 

CheckBoundary( a". detail ); 
Make Check (a, dgm) ; 
a  :=  a''. next; 
end;  (*  while  *) 
end;  (*  then  *) 
end;  (*  CheckBoundary  *) 

begin 

d  :=  dgm; 
while  d  <>  nil  do 
begin 

a  :=  d'^.acts; 
while  a  <>  nil  do 
begin 

MakeDgmLink(dgm,a); 
a  :=  a''. next; 
end;  (*  while  *) 
d  :=  d'^.next; 
end;  (*  while  *) 
count  :=  0; 
d  :=  dgm; 
while  d  <>  nil  do 
begin 
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if  not  d^.hasparent 
then 
begin 

count  :=  count  +1; 
parent  :=  d; 
end;  <*  then  *) 
d  :=  d'^.next; 
end;  (*  while  *) 
i  f  count  =  0 
then  err(8) 
else  if  count  >  1 
then 
begin 
err(9); 
d  :=  dgm; 
while  d  <>  nil  do 
begin 

if  not  d'^^.hasparent 
then 
begin 

write('   diagram;   '); 
PrintWordCd". name, true) ; 
end;  (*  then  *) 
d  :=  d^.next; 
end;  (*  while  *) 
end  <*  then  *) 
else 
begin 

writeln( 'Beginning  Intra-diagram 

Consistency  Check'); 
CheckWithinCparent) ; 
writeln( 'Completed  Intra-diagram 

Consistency  Check'); 
writeln( 'Beginning  Inter-diagram 

Consistency  Check'); 
CheckBoundaryCparent) ; 
writeln( 'Completed  Inter-diagram 

Consistency  Check'); 
end;  <*  else  *) 
end;  (*  CheckConsistency  *) 

begin   (*  main  *) 
error  :=  false; 
cccc  : =  '  ' ; 
dgm  :=  nil; 
1 ine  :=  1 ; 
write  In; 
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writeln( 'Beginning  Input  Scan'); 
if  not  eof 
then 
begin 

GetWord(word,  line); 
if  word  =  'DIAGRAM:' 
then 
begin 

GetWord(word,  line); 
GetDgmCdgm,  word,  line); 
end  <*  then  *) 
else  err(l); 
end;  (*  then  *) 
if  error 
then 
begin 

writeC 'Processing  Stopped  At  "'); 
PrintWordCword, false); 
writelnC"  Near  Line  ',  line:2); 
end  (*  then  *) 
else 
begin 

writelnCCompleted  Input  Scan'); 
writeln( 'Beginning  Echo  Of  Input'); 
Pr intDgmsCdgm) ; 

writelnCCompleted  Echo  Of  Input'); 
CheckConsistencyCdgm) ; 

writeln( 'Completed  Consistency  Check'); 
if  not  error  then  writelnCNo  Errors  Encountered'); 
end;  (*  else  *) 
end.  (*  main  *) 
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ABSTRACT 

Requirements  specifications  are  the  basis  for  develop- 
ing a  system,  defining  the  problem  and  outlining  the  char- 
acteristics (including  constraints)  of  a  correct  solution. 
The  requirements  specification  must  answer  questions  about 
the  system,  but  an  inconsistent  specification  is  unable  to 
do  this  because  the  specification  contains  contradictions. 
The  requirements  specification  should  be  analyzable  for 
consistency.   Automated  tools  enable  easier  and  more 
accurate  analysis. 

Structured  analysis  diagrams  are  a  system  for  con- 
cisely specifiying  requirements  of  large  scale  systems,  yet 
inconsistencies  are  possible  in  naming  information  at 
different  abstraction  levels.   Extensions  to  data  element 
names  showing  the  element's  source  and  sink  enable  computer 
tools  to  insure  consistency. 

A  consistent  requirements  specification  is  a  necessity 
when  developing  a  system.   Consistency  checking  of  require- 
ments specifications  is  one  method  of  possibly  reducing  the 
number  of  errors  in  the  implementation  of  a  system,  and  is 
therefore  beneficial.   By  reducing  the  number  of  errors  in 
a  system  early  in  the  development  process,  the  probability 
of  a  correct  solution,  and  a  solution  with  less  cost,  is 
increased. 


